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CORE A server object maintains a registry of filters contain- 
ing unique identifiers and specifications for each of the 
filters and the order in which the filters must be applied. The 
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received from the server. Filters may also be present in the 
client side of the ORB in order to execute code before and 
after the marshaling and unmarshaling that takes place in the 
client side of the ORE and these latter filters are also 
included in the client filter registry. The client then uses its 
filter registry to invoke the filters during a subsequent 
method invocation. The client also receives a time stamp 
from the server to identify the current filter composition. In 
method invocations to the server, the client includes the 
value of the time stamp it received and the server returns an 
exception to the cMent if the time stamps do not match. In 
response to this exception, the client re-invokes the 
_retrieve__filtersO method in order to obtain the most recent 
fiher registry contents and lime stamp from the server. 
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METHOD AND APPARATUS FOR cedural code that presented a simple, command line inter- 

EXECUTING CODE DURING METHOD face and text display to the user. These simple programs 

INVOCATION ^^^^ gradually been replaced with complex programs that 

have graphical user interfaces and multiple features. 

CROSS REFERENCE TO RELATED ^ ^ programs have grown in complexity, the amount of 

APPLICATIONS effort which is required to write and debug the programs has 

The following U.S. patent applications are related to the also increased drastically. Consequently, major efforts have 

present application and are incorporated by reference herein ^^en made to reduce the amount of programming necessary 

in their entirety produce a modem, full-featured product. One of the most 

U.S. patent application Ser. No. 08/554,794, filed Nov. 7, lo s^iccessful of these efforts has been the development of 

innr *• . ito * * r *• o obiect-oriented programming in which programs are 

1995 as a contmuation to U.S. patent application Ser. . n ** . i * ii 7u i.- 

Kr o^-» ci j m inno / u A j\ designed as collections 01 discrcte elements calkd objects . 

No. 07/995,853, filed Dec. 21, 1992 (now abandoned); t^. . u jc ^ j j • 

^ Ine objects can be modified and re -used in many cases, 

U.S. patent application Ser. No. 08/670,682, filed Jun. 26, j^ereby reducing the developmem effort. 

j5 As will be understood by those skilled in the art, objects 

U.S. patent application Ser. No. 08/673,181, filed Jun. 26, ^^e context of object-oriented programming are software 

^^^^i entities comprising data and methods or operations on that 

U.S. patent application Ser. No. 08/670,700, filed Jun. 26, data. The methods of an object collectively form an interface 

1996; for manipulating the data in the object. The objects exist 

U.S. patent application Ser. No. 08/670,681, filed Jun. 26, 20 o^^X program runtime and are created, or instantiated, 

1996; from object "classes" which are actually written by the 

U.S. patent application Ser. No. 08/670,684, filed Jun. 26, programmer. The class code written by a programmer can be 

1996; "reused" by another programmer by instantiating objects 

U.S. patent application Ser No. 08/669,782, filed Jun. 26, from that code. 

1996; 25 order to further reduce the programming burden, dis- 

U.S. Patent Application entitled "Method and Apparatus tributed object systems have been developed in which 

for Deferred Throwing of Exceptions in C++", filed by methods in objects resident on a server can be executed or 

Christian J. Callsen and Ken M. Cavanaugh, assigned invoked remotely over a network from a chent application, 

attorney docket no. 6205491 and filed on an even date In Ihis manner, the objects can be developed and maintained 

herewith; 30 t>y a party different from the party that developed the client 

U.S. Patent AppHcation entitled "Method and Apparatus application. In such a system information is routed or 

for Fast, Local CORBA Object References", filed by streamed between the client and the server. This information 

Christian J. Callsen and Ken M. Cavanaugh, assigned includes requests from the client to invoke an object on the 

attorney docket no. 08/993,800 and filed on an even ^^^^^^ ^^^^ ^^om the method invocation 

date herewith* 35 returning from the server to the client. In addition, object- 

U.S. Patent Application entitled "Method and Apparatus ^"^^^^ programs often communicate by streaming objects 

for Constructing Stable Iterators in a Shared Data ^^^"^ P^^^ram to another. 

Collection", filed by Christian J. Callsen and Ken M. ^^^^ streammg operations, a stream wnter organizes, 

Cavanaugh, assigned attorney docket no. 6016489 and marshals, the information to form a serial data stream, 

filed on an even date herewith; The serial data stream is then sent to the server where a 

U.S. Patent AppHcation entitled, "Method and Apparatus unmarshals the serial data stream to recon- 

for Enforcing Locking Invariants in Multi-Tlireaded ^ ^^^^[^^J mformaUon. The stream reader 

Systems^ filed by Christian J. Callsen and Ken M. must operate such that the unmarshahng exactly ^ undoes 

Cavanaugh, assigned attorney docket no. 08/993,206 f^^^ ^he marshahiig so that the original mformation 

and filed on an even date herewith; reconstructed. Ordmarily, such an operation does not 

U.S. Patent AppHcation entitled, "Method and Apparatus I'^'f^^ ' problem but when the stream reader ^ not written 

for Efficient Representation of Variable Length Identi- same author as the stream writer there can be 

fiers in a Distributed Object System", filed by Ken M. mcompatimmies 

Cavanaugh, assigned attorney docket no. 08/993,204 ' f ^^^ardize the marshalmg and unmai^hahng 

and filed on an even date herewith; and ^""^ ^^^^ ^^^"'^^^ P^°^^^^' consortium called the 

U.S. Patent Application entitled, "Marshaling And ^^^^^ Managen^ent Group (OMG) w^ formed whose 

rr u 1- r: 1 T- o 4.' T A mission is to define a set of mterfaces for mter-operable 

Unmarshaling rramework For Supporting rilters in A t* ^ * .i_ ^ /^t_- .if 

r>»' . u » J rfu- *o * j» ci J L A T- J 1 1^ software. Its first specification, the Common Obiect Request 

Distributed Object System", filed by Anita Jindal, Ken 1 a u * rr^r^ni^ a\ • ■ j . 

^ u J o • ■ u • J \* Broker Architecture (CORBA) specification, is an industry 

M. Cavanaugh and Sanjeev Knshnan, assigned attor- ^ . ^ j . i. ^ if l 

J 1 * no/nn-. jcij j*55 conscnsus Standard that hides all differences between pro- 

ney docket no. 08/993,263 and filed on an even date .1 . , » . • . 1 

herewith gramming languages, operating systems, and object loca- 
tion. The CORBA standard defines an object request broker 

HELD OF THE INVENTION (ORB) that handles the marshaling, transport and unmar- 

This invention relates to distributed object systems using ^^^^i^g of inforaiation between applications. The ORB 

common object request broker architecture (CORBA) and, functions as a communication infrastructure, transparently 

more particularly, to a method and apparatus for providing relaying object requests across distributed heterogeneous 

a filter framework for the execution of code during a method computing environments. Inter-operability is accompHshed 

invocation. through well-defined object interface specifications which 

allow client applications to connect to the ORB. CORBA 

BACKGROUND OF THE INVENTION ^5 provides an implementation independent notation for defin- 

Software programs are continually becoming more com- ing interfaces called the OMG Interface Definition Lan- 

p Heated. Early programs consisted of straightforward pro- guage (IDL). 
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The OMG CORE A specification defines an implementa- 
tion independent object model which is actually built with a 
programming language, such as C-h- or Java. In this model 
CORBA objects (also called "servants"), which arc imple- 
mented by servers, have references that can be exported to S 
clients. CUents and servers arc roles, not mutually exclusive 
tasks for a single program, so that any one program can be 
both a client and a server. Objects and object references are 
typically different programming language objects, although 
they do not have to be. lo 

In a server, the implementation of an actual object which 
can be used to satisfy an invocation on a CORBA object is 
generally both platform and language dependent and various 
models are possible for implementing objects in servers. The 
original CORBA standard defined a Basic Object Adapter 
(or BOA) which is a framework that adapts the server 
implementation to the implementation independent ORB. A 
newer OMG portability standard defines a Portable Object 
Adapter (or POA), which replaces the BOA and is intended 
to be platform independent. Many ORBs also support other 
proprietary frameworks for implementing CORBA objects. 
All of these frameworks are commonly referred to as Object 
Adapters (or OAs). 

An application programmer using object request broker 
technology may want to execute code segments as a part of 
the method invocation process, specifically during the mar- 
shaling and unmarshaling processes. Such code segments 
may operate to monitor and debug a program, or to imple- 
ment security mechanisms, for example. Filters, that is, 
sections of code which execute during the method invoca- 
tion process before or after marshaling or unmarshaling of 
arguments in an object request broker system, are known. 
Filters may be used to perform a variety of tasks, such as 
compression, encryption, tracing, or debugging, that may be 
applied to communications to or from an object. However, 
such filters are typically statically defined for client and 
server objects and compiled with the client and server code, 
respectfully. 

Simulation, debugging, and other operations would be 
greatly enhanced if filters could be defined and modified 
during system operation. 

SUMMARY OF THE INVENTION 

In accordance with the principles of the invention, one or 45 
more filters may be included in the skeleton code for each 
object implementation and each server object maintains a 
registry of filters containing unique identifiers and specifi- 
cations for each of the filters and the order in which the 
filters must be applied. The filters execute selected code 50 
either before or after the conventional marshaling and 
unmarshaling which take place during a method invocation. 

The client includes a filter registry, which is built when 
the cUent side ORB invokes a special method, _retrieve_ 
filtersQ, on a server In response to a _retrieve_filtcrsO call, ss 
the server passes the identification of the filters associated 
with an object implementation, and the order in which they 
should be invoked, to the client. The client constructs a 
registry of filters arranged in the order they should be 
applied, and uses this filter registry during subsequent 60 
method invocations. 

In accordance with another aspect of the invention, filters 
may be added to or subtracted from the filter list during 
system operation without bringing down the server. The 
server initializes a timestamp to identify the current filter 65 
composition and updates the timestamp with each modifi- 
cation to its filter registry. When a client retrieves a list of the 
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filters available on the server, using the „retrieve_filters() 
method, the server passes the time stamp to the client. In 
subsequent method invocations to the server, the client 
includes the value of the time stamp it received. The server 
compares the time stamp in the method invocation to its own 
time stamp and returns an exception to the client if the time 
stamps do not match. In response to this exception, the ctient 
re-invokes die _retrieve_filtersO method in order to obtain 
the most recent filter registry contents and time stamp from 
the server. The client then proceeds to re -invoke the method 
using the newly received filter list and time stamp . 

In another aspect of the presently preferred embodiment, 
filter code may be downloaded on the client side during 
system operation when the ORB supports class 
downloading, such as a Java-based ORB. In the Java-based 
environment, the application programmer registers both the 
client and server side filter code with an object implemen- 
tation. The client side ORB invokes _retrieve_filtersO 
method and receives an ordered list of filter identifications. 
The client side ORB then, dynamically loads the filter code 
from the server using a Java class loader, creates a new 
instance of the loaded filter class, and stores the new 
instance in the client side filter registry. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the invention may be 
better understood by referring to the following description in 
conjunction with the accompanying drawings in which: 

FIG. 1 is a schematic block diagram of an illustrative prior 
art hardware platform which forms part of a computer 
system on which the invention can be run. 

FIG. 2 is a schematic diagram of a prior art computer 
network system on which a CORBA system can be built. 

FIG. 3 is a block schematic diagram illustrating a prior art 
CORBA environment. 

FIG. 4 is a block schematic diagram illustrating a CORBA 
environment including client and server filters constructed in 
accordance with the principles of the invention. 

FIG, 5 is a block schematic diagram illustrating a more 
detailed view of the client and server filter registries, in 
accordance with the principles of the invention. 

FIG. 6 is a flowchart illustrating the registration of filters 
in accordance with the principles of the present invention. 

FIGS. 7A and 7B combine to form a flowchart illustrating 
the maintenance of dynamic filter lists in accordance with 
the principles of the present invention. 

FIG. 8 is a flowchart illustrating the downloading of filter 
code by a client in accordance with the principles of the 
present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

FIG. 1 illustrates the system architecture for an exemplary 
client computer 100, such as an IBM THINKPAD 701® 
computer or Digital Equipment Corporation HiNote™ 
computer, on which the disclosed network access system 
(system) can be implemented. The exemplary computer 
system of FIG. 1 is discussed only for descriptive purposes, 
however, and should not be considered a limitation of the 
invention. Although the description below may refer to 
terms commonly used in describing particular computer 
systems, the described concepts apply equally to other 
computer systems, including systems having architectures 
that are dissimilar to that shown in FIG. 1. 

The client computer 100 includes a central processing unit 
(CPU) 105, which may include a conventional 
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microprocessor, random access memory (RAM) 110 for 
temporary storage of information, and read only memory 
(ROM) 115 for permanent storage of information. A 
memory controller 120 is provided for controlling system 
RAM 110. A bus controller 125 is provided for controlling s 
bus 130, and an interrupt controller 135 is used for receiving 
and processing various interrupt signals from the other 
system components. 

Mass storage may be provided by diskette 142, CD-ROM 
147, or hard disk 152. Data and software may be exchanged 
with client computer 100 via removable media, such as 
diskette 142 and CD-ROM 147. Diskette 142 is insertable 
into diskette drive 141, which is connected to bus 130 by 
controller 140. Similarly, CD-ROM 147 is insertable into 
CD-ROM drive 146, which is connected to bus 130 by 
controller 145. Finally, the hard disk 152 is part of a fixed 
disk drive 151, which is connected to bus 130 by controller 
150. 

User input to the client computer 100 may be provided by 
a number of devices. For example, a keyboard 156 and a 20 
mouse 157 may be connected to bus 130 by keyboard and 
mouse controller 155. An audio transducer 196, which may 
act as both a microphone and a speaker, is connected to bus 
130 by audio controller 197. It should be obvious to those 
reasonably skilled in the art that other input devices, such as ^ 
a pen and/or tablet and a microphone for voice input, may 
be connected to client computer 100 through bus 130 and an 
appropriate controller. DMA controller 160 is provided for 
performing direct memory access to system RAM 110. A 
visual display is generated by a video controller 165, which 30 
controls video display 170. 

Qient computer 100 also includes a network adapter 190 
that allows the client computer 100 to be interconnected to 
a network 195 via a bus 191. The network 195, which may 
be a local area network (LAN), a wide area network (WAN), 35 
or the Internet, may utilize general purpose communication 
lines that interconnect multiple network devices. 

Client computer system 100 generally is controlled and 
coordinated by operating system software, such as the 
WINDOWS 95® operating system (available from 40 
Microsoft Corp., Redmond, Wash.). Among other computer 
system control functions, the operating system controls 
allocation of system resources and perforins tasks such as 
process scheduling, memory management, networking and 
I/O services. 45 

FIG. 2 illustrates, in a very simple fashion, the connection 
of a number of computing systems, such as that shown in 
FIG. 1, to form a distributed computing facility. Each of the 
individual stations 200, 202, 204, 208 and 210 are intercon- 
nected by a network mechanism. Although the distributing 50 
computing facility could exist on a single computing system, 
it is more likely to operate over a network transport medium. 
Such a transport medium may be LAN as shown in FIG. 2, 
but may also be other network arrangements, including the 
Internet. All that is necessary is that the terminals 200, 202, 55 
204, 208 and 210 be able to communicate with each other 
using predefined protocols to exchange information. As 
previously mentioned, the CORBA architecture overlays 
such a network and relieves the individual applications from 
dealing with the details of transporting information over the 60 
network. More particularly, the CORBA architecture hides 
all of the details and the actual network protocols from the 
application programs. It assures that the application pro- 
grams operate with each other regardless of the platforms on 
which the software is designed to run and regardless of the 65 
network protocols used to interconnect separate computing 
systems. 
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FIG. 3 illustrates, in a very schematic form, the basic 
CORBA architecture which defines a peer-to-peer distrib- 
uted computing facility where ail applications are objects (in 
the sense of object orientation). Objects can alternate 
between client roles 300 and server roles 302. An object 
operates in a client role 300 when it is the originator of an 
object invocation. An object operates in a server role 302, 
called an object implementation, when it is the recipient of 
an object invocation. 

The client 300 communicates with the server 302 by 
means of an object request broker or ORB 308. The ORB 
308 operates with a transport 310 that conveys information 
between the client 300 and server 302 and, as previously 
mentioned, the ORB 308 handles the marshaling, transport 
and unmarshaling of information between client 300 and 
server 302. The client 300 communicates with the ORB 308, 
as indicated schematically by arrow 304, by means of an 
implementation independent syntax which describes object 
encapsulations. This syntax is caUed an interface definition 
language (IDL) and is defined in the CORBA specification 
generated by OMG. The OMG interface definition language 
can be used to define interfaces that have attributes and 
operation signatures. The language also supports inheritance 
between interface descriptions in order to facilitate reuse by 
developers. Objects or servants in the server 302 export 
object references with interfaces specified by the OMG IDL 
for use by clients. The object reference contains an identi- 
fication of the object implementation so that the server 302 
can pass a request to the correct object. 

The entire CORBA architecture is actually implemented 
in a conventional programming language, such as C, C++, 
Java, or Smalltalk. Implementations in a variety of lan- 
guages are available from a number of vendors who typi- 
cally provide an IDL compiler bundled with their ORB 
products. The IDL compilers generate header files which 
define the OMG IDL interfaces and can be incorporated into 
application programs. The IDL compilers also generate stub 
code 306 and skeleton code 314 for each interface. 

The client application program 300 can link directly to the 
OMG IDL stub code 306. As far as the client appHcation 
program is concerned, an invocation of the stub code 306 
appears to be a local function call. Once invoked, the stub 
code 306 provides an interface to the ORB 308 thai performs 
marshaling to encode and unmarshaling to decode the opera- 
tion's parameters into/from communication formats suitable 
for transmission on the transport 310 to/from the server 302. 

At the server side, the OMG IDL skeleton code 314 is the 
corresponding implementation of the OMG IDL interface. 
When the ORB 308 receives a request, the skeleton code 314 
unmarshals the request parameters and generates a call, 
indicated schematically by arrow 312, to an object imple- 
mentation in the server 302. When the server completes 
processing of the request, the skeleton code 314 and stub 
code 306 return the results to the client program 300. If an 
error has occurred, exception information generated by the 
server or by the ORB is returned. 

An object adapter 316 comprises the interface between 
the ORB 308, the skeleton code 314 and the server 302. 
Object adapters, such as adapter 316, support functions, 
such as registration of object implementations and activation 
of servers. There are many potential types of object adapters, 
depending on the purpose of the adapter. The original 
CORBA specification defined only a general-purpose Basic 
Object Adapter or BOA. The BOA performs some basic 
functions. For example, when a client request specifies an 
inactive server process, the BOA automatically activates the 
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server process. When the server is activated it registers its 
implementation with the BOA. The BOA then stores this 
registration to use in future object requests. After an object 
is activated, it can receive client requests by means of a 
callback method in the skeleton code 314. BOA services also 5 
include exception handling and object reference manage- 
ment. 

The block schematic diagram of FIG. 4 illustrates the 
addition of filters to the FIG. 3 ORB architecture. In FIG. 4, 
elements which correspond to elements in FIG. 3 have been 
given corresponding numeral designations. For example, 
stub code 306 in FIG. 3 corresponds to stub code 406 in FIG. 
4. On the client side, the client 400 interacts with the stub 
code 406 which, in turn, communicates with the ORB 408. 
The ORB 408 contains implementations of the client side ^5 
filters 422-436. On the server side, the object adapter 416 
contains implementations of the server side filters 438-452. 

Filters are classified in accordance with the relative place 
within a method invocation process where they are applied 
and depending on the type of message to which they are 
applied. Thus, the filters can be categorized as pre-request, 
post- request, pre-reply, and post-reply filters. The pre- 
request filters 422 and 450 are applied before marshaling 
424 of arguments on the client side in a request message and 
before unmarshaling 448 the request arguments in the skel- 
eton 414. The post-request filters 426 and 446 are applied 
after marshaling 424 of arguments on the client side and 
after unmarshaling 448 the request arguments in the skeleton 
414. It should be noted that, although only one element is 
shown for each type of filter in FIG. 4, there may actually be 
several separate pre -filters, several separate post-filters, etc. 
Each filter can be separately enabled or disabled. 

Similarly, the pre-reply filters 438 and 434 are applied 
before marshaling 440 of the reply results in the skeleton 
414 and before unmarshaling 432 the reply results at the 
client side. The post-reply filters 442 and 430 are applied 
after marshaling 440 of result values on in the skeleton 414 
and after unmarshaling 432 the results at the client side. 

Transform filters may also be employed to implement 40 
encryption and decryption of data or data compression. For 
example, client transform filter 428 could be employed to 
encrypt data which is decrypted by server transform filter 
452 and server transform filter 444 would in turn encrypt 
data which is decrypted by client transform filter 436. There 45 
are two kinds of transform filters supported in the presently 
preferred embodiment of the invention, the request filter and 
the reply filter. The request filters, 428, 452, are invoked on 
the cUent side after all pre and post filters have been applied 
to the request message and on the server before pre and post 50 
filters are applied to the request message. The reply filters, 
444, 436, are invoked on the server side after all pre and post 
filters have been applied to the reply message and on the 
client side before pre and post filters are appfied to the reply 
message. The transform filters are applied only to the 55 
message body, not to the message header, because the object 
which is a part of the message header contains information 
that is required by the object request broker for dispatching 
the message to the appropriate subcontract and for selecting 
what particular transform filters to apply. However, a gg 
dummy message header could be generated in accordance 
with conventional protocols to allow for the application of 
transformation to the message header. This would allow for 
a proper dispatching to the correct subcontract. 

Filters are registered in both the client and the server 65 
before they can be used. The client side filter registry 418 
and the server side registry 420 are illustrated in more detail 
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in FIG. 5. As with FIG. 4, elements in FIG, 5 which 
correspond to elements in FIGS. 3 and 4 have been given 
corresponding numeral designations. Generally, the order of 
filter application is important so that linked lists of filters are 
actually registered. The linked list indicates both the filters 
and the their order of application. Filters are implementation 
specific, so that the server side registration takes place at the 
implemenladon level. The client side registration takes place 
at the object request broker level, since the client is unaware 
of the implementation of an object. 

Referring to FIG. 5, the client 500 includes a filter registry 
518 which includes unordered mappings from filter identi- 
fiers 519 and 523 to client filter implementations 521 and 
525, respectively. There is one client filter registry for each 
client process, where each entry includes the filters to be 
invoked on the client side, associating filter names and 
implementations. These could be the filters registered with 
the ORB on the client side using _rcgistcr_filtcrsO, or those 
that are dynamically downloaded from the server. A filter 
implementation group 523 includes ordered filter interface 
lists for pre-filters 554, post -filters 556, and transform-filters 
558, Such lists are preferably created by the ORB in 
response to a _retrieve_filtersO invocation. Each client 
object, that is, each client side representation of a CORE A 
object found in a process, has a filter implementation group 
523. In the presently prefenred embodiment, the client 
contains a cache which maintains a mapping from object 
implementation identifiers to filter implementation groups. 
The object implementation identifiers include the host name 
of a the server, the server ID, and the implementation ID. On 
the server side, registration takes place on an object imple- 
mentation level. Therefore, the server 502 includes many 
filter registries 520, of which filter registry 1, 560 and filter 
registry 2, 574 are shown. Each registry contains linked lists 
of pre-, post-, and transform filter identifications. For 
example filter registry 560 on the server side, using the 
numbers from the filter implementation group 523 on the 
chent side, contains three fists, fist 562 corresponding to 
pre-filters, fist 564 corresponding to post-filters and list 566 
corresponding to transform-filters. Similarly, filter registry 
574 contains three lists, list 568 corresponding to pre-filters, 
list 570 corresponding to post-filters and list 572 corre- 
sponding to transform-filters. Each of registries 560 and 574 
also contain time stamps 567 and 573, respectively. These 
time stamps are used, as discussed in detail below, to 
indicate the current composition of the corresponding filter 
registry. 

Two filter registration application programming interfaces 
(APIs): "_register_filterO", and "_remove__filterO", are 
located on the object request broker object which enable 
program developers to register and remove filters on the 
client side. There are four filter registration APIs on the 
server: "_register_filt6rO", "_register_filter_afterO", 

"_register__filter__beforeQ" and " remove__filterO'*. These 

APIs permit the server to register a filter either at a default 
location (the end of the linked list) or relative to a 
previously -registered filter in the list of filter names. The 
remove API removes a specified filter. The filters are reg- 
istered by name and each filter has a unique name which can 
be generated hierarchically. 

The flowchart of FIG. 6 illustrates the server filter regis- 
tration process. Registration begins at step 600, then pro- 
ceeds to decision block 602, where it is determined whether 
more filters are to be registered or not. If there arc more 
flhers to register, the process proceeds to step 604, where the 
next filter is registered using the APIs described above. From 
step 604, the process returns to step 602. In case there are no 
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more filters to be registered, the process proceeds from step 
602 to step 606, where the server generates a timestamp. The 
timcstamp may be an actual time designation or any other 
designation which indicates a time ordering. For example, 
the timestamp could be a combination of Unix time and the 
process ID, or simply a number which monotonically 
increases. The timestamp is saved with the filter list and 
updated whenever there arc any changes to the filter list. 
After step 606, the process proceeds to its termination at step 
608. 

A client can obtain a list of all filters supported by the 
server *s implementation by making the special method call, 
"_retrieve_filtersO", to the server. The server returns three 
lists of the names of all pre-, post- and transform filters 
associated with the object implementation. The client can 
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la another aspect of the invention, filter code may be 
dynamically downloaded on the cUent side. In this way the 
client application programmer can use filters without pro- 
gramming them or understand what kind of filters need be 
provided. This type of operation is particularly useful with 
an ORB based on a Java implementation which supports 
class downloading. In such a system, a client programmer 
simply writes a normal apphcation; the Java object request 
broker itself takes care of discovering and applying filters. 
This process is illustrated in the flow diagram of FIG. 8, 
where the process starts in step 800 and proceeds to step 802 
where the client invokes a "__retrieve_filtersO" method. 
With this step the client retrieves fully qualified filter names 
from the server. The process then proceeds to step 804 where 
the client employs a Java class loader to download a selected 



then construct a list of filters in the order in which they filter class. The process then proceeds to step 806 where the 



should be applied. In an alternative embodiment, filter lists 
for all implementations can be cached at the host imple- 
mentation ID level. 

In the presently preferred embodiment of the invention, 



client creates a new instance of the loaded class using the 
class constructor method. The process then proceeds to step 
808 finish. 

A software implementation of the above-described 



medium, including but not limited to optical or analog 
communications lines, or may be implemented with wireless 
techniques, including but not limited to microwave, infrared 
or other transmission techniques. It may also be the Internet. 
The series of computer instnictions embodies all or part of 
the functionality previously described herein with respect to 
the invention. Those skilled in the art will appreciate that 
such computer instmctions can be written in a number of 



the lists of filters can be changed any time, even as the 20 embodiment may comprise a series of computer instructions 
system is running. Conventional systems require that the either fixed on a tangible medium, such as a computer 
server be shut down in order to notify clients of the new filter readable media, e.g. diskette 142, CD-ROM 147, ROM 115, 
list. Rather than requiring the client to request current filter or fixed disk 152 of FIG. 1, or transmittable to a computer 
lists each time an invocation is made, the timestamp previ- system, via a modem or other interface device, such as 
ously mentioned is used to "authenticate" the filter list used 25 communications adapter 190 connected to the network 195 
by the client at the server side before application of the over a medium 191. Medium 191 can be either a tangible 
filters. Specifically, after the timestamp has been obtained, in 
all subsequent method invocations, the client sends its copy 
of the time stamp to the server in the service context list field 
of the request message. The server retrieves the time stamp 
from the context list field and compares it against its own 
timestamp copy, which it updates with adjustments to the 
filter Ust. If there is a mismatch in timestamps, the server 
returns an exception to the client and, in response, the client 

re-invokes the " retrieve filtcrsQ" method on the server to . , ^ * u- 

obtain a new fllur list and the laVest timestamp. TTie cUent P^J^^^m languages for u«! with many computer archi. 

- lectures or operating systems. Further, such instructions may 

be stored using any memory technology, present or future, 
including, but not limited to, semiconductor, magnetic, 
optical or other memory devices, or transmitted using any 
40 communications technology, present or future, including but 
not limited to optical, infrared, microwave, or other trans- 
mission technologies. It is contemplated that such a com- 
puter program product may be distributed as a removable 
media with accompanying printed or electronic 
the filter lists, the process proceeds to step 706, where the 45 documentation, e.g., shrink wrapped software, pre-loaded 
client invokes the method as shown in steps 422 through 428 with a computer system, e.g., on system ROM or fixed disk, 
in FIG. 4. During the method invocation process, the chent or distributed from a server or electronic bulletin board over 
includes the copy of the time stamp that it obtained from the a network, e.g., the Internet or World Wide Web. 
server in step 704 in the service context list of the request Although an exemplary embodiment of the invention has 
message. In step 708, the server receives the method invo- 50 ^^^^ disclosed, it wiU be apparent to those skilled in the art 
cation and retrieves its own timestamp, which wdl have been ^^^^ ^^^-^^ modifications can be made which 

updated to reflect any adjustments to the filter hst. will achieve some of the advantages of the invention without 

In step 710, the server compares the time stamp received departing from the spirit and scope of the invention. It will 

be obvious to those reasonably skilled in the art that other 



then reinvokes the method, using the new filters and times- 
tamp. 

This process is set forth in a flow diagram of FIGS. 7A 
and 7B which starts at step 700 and proceeds to step 702 
where the client invokes a "_retrieve_filtersO'* method on 
the server before invoking any other method. In response, 
the server returns the filter lists and time stamp in step 704. 
The filter lists are three lists of filter names: one each for 
pre-filters, post-filters, and transform filters. After reluming 



from the client to its own, updated, time stamp. The process 



then proceeds via off-page connectors 714 and 718. to components performing the same functions may be suitably 



60 



decision block 720. The server compares the timestamps 
and, if the timestamps do not match, the process proceeds to 
step 722 where the server returns a "_rebind_filtei:sO" 
exception to the client. Following the "„rebind__filtersO" 
exception, the process proceeds, via off-page connectors 716 
and 712, back to step 702 where the client re-invokes the 
"_retrieve_JilterO" method in order to obtain the latest 
filler list and timestamp from the server, as previously 
described. 

If, in step 720, the time stamps are found to be equal, the 
process proceeds to step 724, where the server processes the 65 
client method invocation and then proceeds to step 726 to 
finish. 



substituted. Further, the methods of the invention may be 
achieved in either all software implementations, using the 
appropriate processor instructions, or in hybrid implemen- 
tations which utilize a combination of hardware logic and 
software logic to achieve the same results. Further, aspects 
such as the size of memory, the specific configuration of 
logic and/or instructions utilized to achieve a particular 
function, as well as other modifications to the inventive 
concept are intended to be covered by the appended claims. 
What is claimed is: 

1. Apparatus for providing a framework for the execution 
of server-specified code at selected points during a method 
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invocation in a distributed object system having clients and 
servers, the apparatus comprising: 

a plurality of server filters, each of the server fillers having 
an identifier and executing selected code during the 
method invocation; 

a server filter registry in the server object, the server filter 
registry containing filler identifiers and a method for 
retrieving the filter identifiers from the registry; and 

a client filter registry in the client object, the client filter 
registry containing filter identifiers, exported from the 
server object and stored in the client filter registry in 
response to an invocation of the method for retrieving 
the filter identifiers w^herein the client object can selec- 
tively invoke one or more of said server filters using the 
filter identifiers in the chent filter registry during a later 
method invocation in the distributed object system. 

2. The apparatus of claim 1 wherein the apparatus 
includes: 

a plurality of filter registries in the server, each registry 
corresponding to an implementation supported by the 
server, each filter registry containing filter identifiers 
and a method for retrieving the filter identifiers from 
the registry; 

a plurality of client filters, each of the client filters having 
an identifier and executing selected code during the 
method invocation; 

a client filter registry in the client, the chent filter registry 
containing filter identifiers and the corresponding client 
side filter implementations, and 

a filter implementation group in each client object, said 
filter implementation group including filter lists con- 
taining cUent side filter implementations, where the 
identifiers of the client side filter implementations 
correspond to the filter identifiers obtained from the 
server object that corresponds to the client object in 
response to the method for retrieving filter identifiers 
from the server object. 

3. The apparatus of claim 2 wherein the filter Usts 
correspond to pre filters, post filters, and transform filters. 

4. The apparatus of claim 1 wherein a method invoked on 
the client object also invokes the filters indicated by the 
client object's filter Usts. 

5. The apparatus of claim 1 wherein the cHent contains a 
filter implementation group cache which maintains a map- 
ping from object implementation identifiers to filter imple- 
mentation groups, where an object implementation identifier 
includes the host name of a server, a server identifier, and an 
implementation identifier. 

6. The apparatus of claim 1 wherein the distributed object 
system includes an object request broker which transmits the 
method invocation from the client object to the server object 
and wherein the server filters are located in implementation 
specific code which connects the server object to the object 
request broker. 

7. The apparatus of claim 6 further comprising a plurality 
of client filters each having an identifier and being located in 
the object request broker. 

8. The apparatus of claim 7 wherein the client filter 
registry includes filler identifiers for both the client filters 
and the server filters. 

9. The apparatus of claim 6 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and the plurafity of 
server filters includes a pre-filter which executes code before 
the marshaling and unmarshaling operates. 

10. The apparatus of claim 6 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
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Operable during the method invocation and the plurality of 
server filters includes a post-filter which executes code after 
the marshaling and unmarshaling operates. 

11. The apparatus of claim 6 wherein the object request 
5 broker includes a marshaling and unmarshaling mechanism 

operable during the method invocation and the plurality of 
server filters includes a pre-filter which executes code before 
the marshahng and unmarshaling operates, a post-filter 
which executes code after the marshaling and unmarshahng 
operates and transform filters which execute code before the 
pre-filter operates and after the post-filter operates. 

12. The apparatus of claim 6 wherein the client object 
utilizes all the server filters efifected in the implementation 
specific code which connects the server object to the object 
request broker. 

13. The apparatus of claim 1 wherein each filter identifier 
is unique. 

14. The apparatus of claim 1 wherein the filter identifiers 
arc hierarchical. 

15. The apparatus of claim 1 wherein the server filter 
registry indicates an order in which the filters arc to be 
invoked. 

16. The apparatus of claim 1 wherein the server filter 
registry and the client filter registry each include an indica- 

^ tion of parameters required by each filter. 

17. The apparatus of claim 1 further including filter 
registration application programmer interfaces whereby fil- 
ters may be added to, and removed from, the plurality of 
fiUers and the server filter registry during distributed object 
system operation. 

18. The apparatus of claim 17 wherein the server filter 
registry includes a storage which stores an indication reflect- 
ing the current composition of the plurality of server filters. 

19. The apparatus of claim 18 wherein the server object 
includes a mechanism which sends the indication to the 
client object. 

20. The apparatus of claim 19 wherein the cUent object 
includes the indication in the method invocation and the 
server object includes a mechanism to alert the client object 
if the indication in the method invocation indicates that the 

40 

client filter registry does not include the current composition 
of the plurality of server filters. 

21. The apparatus of claim 1 further comprising a mecha- 
nism for downloading filter code from the server object to 
the client object so that the client object can run the filter 
code. 

22. A method for providing a framework for the execution 
of cUent-specified code at selected points during a method 
invocation in a distributed object system having client and 
server objects, the method comprising the steps of: 

(a) constructing a plurality of server filters, each of the 
server filters having an identifier and executing selected 
code during the method invocation; 

(b) constructing a server filter registry in the server object, 
55 the server filter registry containing filter identifiers and 

a method for retrieving the filter identifiers from the 
registry; 

(c) constructing a client filter implementation group in the 
client object, the chent filter implementation group 

60 containing client filter implementations corresponding 
to filter identifiers exported from server objects and 
stored in the client filter implementation group in 
response to an invocation of the method for retrieving 
the filler identifiers; and 

65 (d) using the client object to invoke one or more filters in 
the filter implementation group during a later method 
invocation in the distributed object system. 
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23. The method of claim 22 wherein step (d) comprises 
the step of: 

(e) tising the clieat object to selectively invoke filters that 
are flagged as optional by said server. 

24. The method of claim 23 wherein the distributed object 
system includes an object request broker which transmits the 
method invocation from the client object to the server object 
and wherein step (a) comprises the step of: 

(al) constructing the server filters in implementation 
specific code which connects the server object to the 
object request broker. 

25. The method of claim 24 further comprising the step of: 
(e) constmcting a plurality of chent filters each having an 

identifier and being located in the object request broker. 

26. The method of claim 25 wherein step (c) comprises 
the step of: 

(cl) constructing the client filter registry with filler iden- 
tifiers for both the client filters and the server filters. 

27. The method of claim 24 wherein the object request 
broker incltidcs a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the step of: 

(a2) constructing a pre-filter which executes code before 
the marshaling and unmarshaling operates. 

28. The method of claim 24 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the step of: 

(a3) constructing a post-filter which executes code after 
the marshaling and unmarshaling mechanism operates. 

29. The method of claim 24 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the steps of: 

(a4) constructing a pre-filter which executes code before 

the marshaling and unmarshaling operates; 
(a5) constructing a post-filter which executes code after 

the marshaling and unmarshaling mechanism operates; 
(a6) constructing a transform filter which executes code 

before the pre-filter; and 
(a7) constructing a transform filter which executes code 

after the post-filter. 

30. The method of claim 24 wherein step (d) comprises 
the step of: 

(dl) utilizing all the filters effected in the implementation 
specific code which connects the server object to the 
object request broker. 

31. The method of claim 23 wherein step (a) comprises 
the step of: 

(aS) constructing each filter with a unique identifier 

32. The method of claim 23 wherein step (a) comprises 
the step of: 

(a9) constructing the plurality of filters with hierarchical 
filter identifiers. 

33. The method of claim 23 wherein step (b) comprises 
the step of: 

(bl) constructing the server filter registry to indicate an 
order in which the fillers are to be invoked. 

34. The method of claim 23 wherein step (b) includes the 
step of: 

(b2) constructing the server filter registry with an indica- 
tion of parameters required by each filter, and step (c) 
comprises the step of; 

(c2) constructing the client filter registry with an indica- 
tion of parameters required by each filter. 
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35. The method of claim 23 further comprising the step of: 

(f) using filter registration application programmer inter- 
faces to add and remove fihers from the plurality of 
fillers and the server filter registry during distributed 

5 object system operation. 

36. TTie method of claim 35 further comprising the step of: 

(g) storing an indication reflecting the current composi- 
tion of the plurality of server filters in a storage in the 
server object. 

'^^ 37. The method of claim 36 further comprising the step of: 

(h) sending the indication from the server object to the 
client object. 

38. The method of claim 37 further comprising the steps 

15°f= 

(i) including the indication in the method invocation; 
0 receiving the method invocation in the server object; 

and 

(k) alerting the client object if the indication in the 
20 received method invocation indicates that the client 
filter registry does not include the current composition 
of the plurality of server filters. 

39. The method of claim 23 further comprising the step of: 
(1) downloading filter code from the server object to the 

client object so that the client object can run the filter 
code. 

40. A computer program product for providing a frame- 
work for the execution of application program-specified 
code at selected points during a method invocation in a 
distributed object system having client and server objects, 
the computer program product comprising a computer 
usable medium having computer readable program code 
thereon including: 

program code for constructing a plurality of server filters, 
each of the server filters having an identifier and 
executing selected code during the method invocation; 

program code for constructing a server filter registry in 
the server object, the server filter registry containing 
filter identifiers and a method for retrieving the filter 
identifiers firom the registry; 

program code for constructing a client filter registry in the 
client object, the client fiUer registry containing filter 
identifiers, exported from the server object and stored 
45 in the client filter registry in response to an invocation 
of the method for retrieving the filter identifiers; and 

program code in the client object for selectively invoking 
at least one of the server filters lising the filter identi- 
fiers in the client filter registry during a later method 
50 invocation in the distributed object system. 

41. The computer program product of claim 40 wherein 
the distributed object system includes an object request 
broker which transmits the method invocation from the 
client object to the server object and wherein the program 

55 code for constructing filters comprises program code for 
constructing the server filters in implementation specific 
code which connects the server object to the object request 
broker. 

42. The computer program product of claim 41 further 
60 comprising program code for constructing a plurality of 

client filters, each having an identifier and being located in 
the object request broker 

43. The computer program product of claim 42 wherein 
the program code for constructing a client filter registry 

65 comprises program code for constructing the client filter 
registry with filter identifiers for both the client filters and 
the server filters. 
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44. The computer program product of claim 41 wherein program code for including the indication in the method 
the object request broker includes a marshaling and umnar- invocation; 

shaling mechanism operable during the method invocation program code for receiving the method invocation in the 

and the program code for constructing the plurality of filters server object; and 

comprises program code for constructing a pre- filter which $ j / , .u . ... ./..t. ■ j- 

executes code before the marshaling and unmarshaling P^^F^"" ^^^^'"S the client object if the indica- 

operates received method mvocation mdicates that 

45. The computer program product of claim 41 wherein client filter registry does not include the current 
the object request broker includes a marshaUng and unmar- composition of the plurality of server filters, 
shaling mechanism operable during the method invocation 56. The computer program product of claim 40 further 
and the program code for constructing a plurality of filters comprising program code for downloading filter code from 
comprises program code for constructing a post-filter which the server object to the client object so that the client object 
executes code after the marshaling and unmarshaling can run the filter code, 

mechanism operates. 57. A computer data signal embodied in a carrier wave for 

46. The computer program product of claim 41 wherein providing a framework for the execution of application 
the object request broker includes a marshaling and unmar- ^5 program-specified code at selected points during a method 
shaling mechanism operable during the method invocation invocation in a distributed object system having client and 
and the program code for constructing a pluraUty of filters 5^^^^ objects, comprising: 

comprises. , . , program code for constructing a plurality of server filters, 

program code for constnictag a pre-Mter which executes ^^^^ „f ^^^^ g^^^^ .^^^^^^^ 

code before the marshaling and unmarshahng operates; 20 ^^gcuting selected code during the method invocation; 

program code for constructmg a post-filter which executes , „ ... nt. • . • 

c^e after the marshaling and unmarshaling mecha- P'°P'^ ^"^^ constructing a server filter registry m 

nism operates* server object, the server filter registry containing 

program code for constructing a transform filter which filter ident^ers and a method for retrieving the filter 

executes code before the pre-filter; and 25 identifiers from the registry; 

program code for constructing a transform filter which program code for constructing a client filter registry in the 

executes code after the post-filter. client object, the client filter registry containing filter 

47. The computer program product of claim 41 wherein identifiers, exported from the server object and stored 
the program code for invoking at least one of the server in the client filter registry in response to an invocation 
filters comprises program code for utilizing all the filters 30 of the method for retrieving the filler identifiers; and 
effected in the implementation specific code which connects program code in the client object for selectively invoking 
the server object to the object request broker. at least one of the server filters using the filter identi- 

48. The computer program product of claim 47 wherein fiers in the client filter registry during a later method 
the program code for constructing a plurality of filters invocation in the distributed object system, 
comprises program code for constructing each filter with a 35 58. The computer data signal as defined in claim 57 
unique identifier. wherein the distributed object system includes an object 

49. The computer program product of claim 40 wherein request broker which transmits the method invocation from 
the program code for constructing a plurality of filters the client object to the server object and wherein the 
comprises program code for constructing the plurality of program code for constructing filters comprises program 
filters with hierarchical filter identifiers. 40 code for constructing the server filters in implementation 

50. The computer program product of claim 40 wherein specific code which connects the server object to the object 
the program code for constructing the server filter registry request broker. 

comprises program code for constructing the server filter 59. The computer data signal as defined in claim 58 

registry to indicate an order in which the filters are to be further comprising program code for constructing a plurality 

invoked, 45 of client filters, each having an identifier and being located 

51. The computer program product of claim 40 wherein in the object request broker. 

the program code for constructing the server filter registry 60. The computer data signal as defined in claim 59 

comprises program code for constructing the server filter wherein the program code for constructing a client filter 

registry with an indication of parameters required by each registry comprises program code for constructing the client 

filter, and the program code for constructing the client filter 50 filter registry with filter identifiers for both the client filters 

registry comprises program code for constructing the client and the server filters, 

filter registry with an indication of parameters required by 61. The computer data signal as defined in claim 58 

each filter. wherein the object request broker includes a marshaling and 

52. The computer program product of claim 40 further unmarshaling mechanism operable during the method invo- 
comprising filter registration application programmer inter- 55 cation and the program code for constructing the plurality of 
faces for adding and removing filters from the plurality of fiUers comprises program code for constructing a pre-filter 
filters and the server filter registry during distributed object which executes code before the marshaling and unmarshal- 
system operation. ing operates. 

53. The computer program product of claim 52 further 62. The computer data signal as defined in claim 58 
comprising program code for storing an indication reflecting 60 wherein the object request broker includes a marshaling and 
the current composition of the plurality of server filters in a unmarshaling mechanism operable during the method invo- 
storage in the server object. cation and the program code for constructing a plurality of 

54. The computer program product of claim 53 further filters comprises program code for constructing a post-filter 
comprising program code for sending the indication from which executes code after the marshaling and unmarshaling 
the server object to the client object. 65 mechanism operates. 

55. The computer program product of claim 54 further 63. The computer data signal as defined in claim 58 
comprising: wherein the object request broker includes a marshaling and 
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unmarshaling mechanism operable during the method invo- 
cation and the program code for constructing a plurality of 
filters comprises: 

program code for constructing a pre-filter which executes 
code before the marshaling and unmarshaling operates; 
program code for constructing a post-filter which executes 
code after the marshaling and unmarshaling mecha- 
nism operates; 
program code for constructing a transform filter which 

executes code before the pre-filter; and 
program code for constructing a transform filter which 
executes code after the post-filter. 

64. The computer data signal as defined in claim 58 
wherein the program code for invoking at least one of the ^5 
server filters comprises program code for utiUzing all the 
filters effected in the implementation specific code which 
connects the server object to the object request broker. 

65. The computer data signal as defined in claim 64 
wherein the program code for constructing a plurality of 20 
filters comprises program code for constructing each filter 
with a unique identifier. 

66. The computer data signal as defined in claim 57 
wherein the program code for constructing a plurality of 
filters comprises program code for constructing the plurality 25 
of filters with hierarchical filter identifiers. 

67. The computer data signal as defined in claim 57 
wherein the program code for constructing the server filter 



filter registry with an indication of parameters required by 
each filter, and the program code for constructing the client 
filter registry comprises program code for constructing the 
client filter registry with an indication of parameters 
5 required by each filter. 

69. The computer data signal as defined in claim 57 
further comprising filter registration application program- 
mer interfaces for adding and removing filters from the 
plurality of filters and the server filter registry during dis- 

^0 tributed object system operation. 

70. The computer data signal as defined in claim 69 
further comprising program code for storing an indication 
reflecting the current composition of the plurality of server 
filters in a storage in the server object. 

15 71. The computer data signal as defined in claim 70 
further comprising program code for sending the indication 
from the server object to the client object. 

72. The computer data signal as defined in claim 71 
further comprising: 

program code for including the indication in the method 
invocation; 

program code for receiving the method invocation in the 

server object; and 
program code for alerting the client object if the indica- 
tion in the received method invocation indicates that 
the client filter registry does not include the current 
composition of the plurality of server filters. 

73. The computer data signal as defined in claim 57 



registry comprises program code for constructing the server 

filter registry to indicate an order in which the filters are to 30 further comprising program code for downloading filter 

be invoked. code from the server object to the client object so that the 

68. The computer data signal as defined in claim 57 client object can run the filter code, 
wherein the program code for constructing the server filter 

registry comprises program code for constructing the server ***** 
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